Skip to content

GraphiQL separate module #204

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Conversation

jvalkeal
Copy link
Contributor

  • Drop existing single page cdn integration from boot project.
  • Create new spring-graphql-graphiql module containing graphiql integration.
  • Makes graphiql optional which user can pull in as a dependency.
  • spring-graphql-graphiql is a basic npm module which packages itself as
    a jar where boot autoconfig can integrate to.
  • In a npm module graphiql itself is handled as a plain react app which allows
    some customisation like setting logo name to demonstrate how things are passed
    from boot properties into a react app itself.
  • GraphiQlHandler's are changed to handle all traffic into /graphiql order to:
    • Handling main html in /graphiql/explorer
    • Redirect to /graphiql/explorer to get context path under /graphiql/
    • Handle main.js from classpath to get html to load it under /graphiql/
    • Handle config.js as a way to pass configuration options from server side
      and load those into react app. There are various long threads in GH and SO
      discussing this problem and I chose to load settings from a server side.
  • Samples webmvc-http and webflux-websocket are changed to use this module.
    • webmvc-http is as it used to be.
    • webflux-websocket can now use subscription which gets first greeting instead
      of subscription request reply.
  • Fixes Consider graphiQL integration #20
  • Fixes GraphiQL setup to support websockets #131

Other notes:
This is a draft POC, so tests and more work to npm project would be added
later to polish things a bit.

If looking ok then this would give better foundation to think about
security and other things we'd like to have on this layer. Having a full
blown module and react code in typescript makes it easier to tweak things
instead of trying to rely on public stuff on cdn as a static app relying on
an internet access.

Both webmvc-http and webflux-websocket you can use:

query {
  greeting
}

With webflux-websocket when you use:

subscription {
  greetings
}

Where you get:

{
  "data": {
    "greetings": "Zdravo 007"
  }
}

Instead of:

{
  "data": {
    "upstreamPublisher": {
      "scanAvailable": true,
      "prefetch": -1
    }
  }
}

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Nov 27, 2021
- Drop existing single page cdn integration from boot project.
- Create new `spring-graphql-graphiql` module containing `graphiql` integration.
- Makes `graphiql` optional which user can pull in as a dependency.
- `spring-graphql-graphiql` is a basic npm module which packages itself as
  a jar where boot autoconfig can integrate to.
- In a npm module graphiql itself is handled as a plain react app which allows
  some customisation like setting logo name to demonstrate how things are passed
  from boot properties into a react app itself.
- GraphiQlHandler's are changed to handle all traffic into `/graphiql` order to:
  - Handling main html in `/graphiql/explorer`
  - Redirect to `/graphiql/explorer` to get context path under `/graphiql/`
  - Handle `main.js` from classpath to get html to load it under `/graphiql/`
  - Handle `config.js` as a way to pass configuration options from server side
    and load those into react app. There are various long threads in GH and SO
    discussing this problem and I chose to load settings from a server side.
- Samples webmvc-http and webflux-websocket are changed to use this module.
  - `webmvc-http` is as it used to be.
  - `webflux-websocket` can now use subscription which gets first greeting instead
    of subscription request reply.
- Fixes spring-projects#20
- Fixes spring-projects#131
@bclozel
Copy link
Member

bclozel commented Nov 29, 2021

Thanks @jvalkeal !

This PR is indeed a possible solution for #20. We haven't discussed the possible outcomes of that, so we can use this contribution as an example.

This approach brings more flexibility, features and customization opportunities. But it also has some drawbacks:

  • quite a few details are leaking to the GraphQlProperties, the auto-configuration and the GraphiQlHandler
  • this adds a new module to the project
  • this new module ships with a lot of non-java 3rd party dependencies with a specific release cycle and CVE process
  • shipping such a module means we're investing in more features and support for graphiql

In general, this means that we need to decide between:

  1. shipping a basic integration, mostly for developer testing
  2. supporting a complete module with features, customizations - designed for production use and branding

To me, 1) should be preferred as I think many would for fork/work out their own graphiql instance for specific needs in case of 2). What do you think @rstoyanchev ?

@bclozel
Copy link
Member

bclozel commented Apr 20, 2022

We're happy with the current arrangement and we've decided not to invest in this solution.

@bclozel bclozel closed this Apr 20, 2022
@bclozel bclozel added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged labels Apr 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

Successfully merging this pull request may close these issues.

GraphiQL setup to support websockets Consider graphiQL integration
3 participants